讓我們很快的回顧一下。

A. 資料誕生與成長過程(蘿蔔和豬誕生及被養大的過程)
B. 資料收集與處理過程(蘿蔔和豬被送廚師手裡，最後做出湯的過程)
C. 資料產生的後續影響(喝湯的人有沒有掛急診的過程)

B-1.資料匯入(Data EL)：
在找到所有原料所在之後，只載運完整的原始食材，將其運送到集中地，以利後續處理。
在找到所有原始資料之後，提取完整的原始資料(E)，將原料運送(L)到同一存放位置(Data Warehouse)。

B-2.資料清洗(Data Cleansing)：
清洗完整食材，將食材分為可吃及不可吃，將可吃的保留、不可吃的清洗掉或去除。
處理原始資料，決定心目中應該呈現的資料長相，將資料分為可用及不可用(不可辨識/雜亂資料/骯髒資料)，將可用的收斂歸戶歸類，將不可用的歸納成同一類。將資料【處理掉顯而易見的錯誤】。

B-3.資料採礦(Data Mining)：
處理已經清洗完畢的完整食材，視要做出什麼料理，把完整食材處理成符合該道料理的必要食材。
處理已經清洗完畢的乾淨資料，想清楚資料將被運用的方向和目標，運用所有乾淨且可用的資料，透過邏輯判斷或交集聯集等運算，整理並定義出即將被使用的資料。將資料【處理成應用上想看到的正確】。

B-4.資料分析(Data Analysis)：
處理為了料理目標所準備的食材，透過不同的料理方式，產生不同的最終料理。
處理為了分析目標所準備的資料，透過不同的分析方法，得出不同的分析結果。其中，統計學上最常被用於分析的方法有三種：分群分析、迴歸分析、關聯分析。不過，得到分析結果只是最基本的門檻，往後還必須考慮許多相關因素......

事實上，【資料清洗(Data Cleansing)】和【資料採礦(Data Mining)】做的事情，正是稍早資料匯入(Data EL)有提到過的【Transform(轉置)】所涵蓋的範圍，你看看，T這麼複雜的技術過程，活生生被我拆成了兩個階段來解釋，在最初，竟然和EL這麼簡單的兩個小過程擺在一起並稱為ETL？

時代進步、資料科學領域精進，別再ETL一詞帶過所有步驟，它是三個清清白白條理分明的先後步驟：資料匯入(Data EL)、資料清洗(Data Cleansing)、資料採礦(Data Mining)。

該如何實際操作這幾個步驟？在家也能做！

先有台主機，除非手上有上百G的資料要處理，否則一般筆電和PC都已堪用，像我拿來跑股票推薦的電腦，背後用的資料，包含2014至今(900交易日)所有上市櫃個股的交易數據，用的也不過core i5 + 4G RAM，空間也才500G，可能比你正在使用的電腦還差。

當然，如果你要求效率和速度，越高等級的電腦運作速度絕對越快，這是必然的，尤其更後面，如果打算架一個DB Server，可能就還得用到Server等級、一台十多萬的主機，這就又更另當別論了。總之這段只在表示，如果只是剛入門，隨便一台電腦都是夠用的了。

有人可能會考慮租用雲端主機，這部分小馬從未嘗試過，抱歉無法給出任何評比。(小馬對於沒有經驗或不懂的領域，是絕對不會不懂裝懂亂說的。)

下一步，坊間資料庫軟體PostgreSQL DB目前仍是完全免費的；接著你需要一個資料處理的工具，小馬強烈建議使用SQL進行，目前小馬最愛用Navicat Premium作為資料處理的工具，可惜一組授權序號要一千元美金左右，小馬自己買了一套在用。透過Navicat，可以做到資料匯入，運用SQL可以做到資料清洗、資料採礦。如此一來，資料庫必須的軟硬體就都齊全了。

R、Python、ETL tool或許都能做到這幾個步驟，但是，絕對不如SQL來得乾淨俐落，這邊稍微說明一下。

R和Python的門檻，會發生在資料匯入匯出，因為畢竟你並不是直接拿R和Python去架資料庫，在大部分的資料庫架構下，使用R或Python執行資料清洗、資料採礦，就像是「外包廠商」的概念，你必須把要外包的事項清楚的讓外包廠商可以承接，在外包廠商完成後，又要讓自己公司可以接手後續動作，而且被外包走的事項，等於你只能一直透過外包的方式處理，都遠不如自己公司內建立一個可以處理這件事的小組。

最佳的解決方式是ETL tool做資料更新排程+SQL做清洗和採礦，為什麼不用ETL本身的功能去做清洗？因為這是一致性的問題，單純比較ETL tool的功能，和SQL能做到的清洗，毫無疑問後者是比較強的，舉例SQL中over partition想做到的內容，就絕對不可能透過ETL tool的功能做到。

既然如此，我們應該是將所有執行清洗採礦的處理過程，交給SQL一個人，而不是有些處理交給ETL tool、有些處理交給SQL。當然啦~ 除非就是只有自己在用，很清楚自己什麼狀況是用ETL tool處理，什麼狀況是用SQL處理；否則一旦有交接的狀況發生，都只是造成溝通上的無效率罷了。(就算都自己在用，沒隔多久也會忘記吧...)

誠心建議，資料清洗、資料採礦，唯一選擇SQL。

尤其當面臨大規模的資料清洗(像是小馬做過最麻煩的：地址正規化)，或猶如殺豬取豬肋排繁複工法般的資料採礦，背後還必須按部就班建立temp table，才能達到最後目標。這種時候，都不建議使用R或Python去執行，其實對我而言，R或Python比較像是具有特定目的和用途的工具，例如R有arulesViz，專門做關聯分析結果的圖表；Python有很好的爬蟲功能。比較不是拿來做資料處理的工具。

資料處理，唯一選擇SQL。(不厭其煩地重述！)

當走到最後一個步驟【數據分析】時，我們擁有非常多的選擇，R有直接的套件可以做關聯分析，特定的統計軟體能做許多統計分析，而最簡易也最沒有門檻的(唯一門檻是統計學知識)，莫過於Excel的【分析工具箱】(可透過增益集安裝)，專門被我們拿來做迴歸和假設檢定：

不知各位看到這會不會忍不住碎念：什麼嘛，前面寫得多厲害，到頭來還不是只用Excel。哈哈...只能說，嘗試過各種工具之後，仍是會回到Excel這種反璞歸真的工具，最為親切。數據分析文章裡本來想提假設檢定，但試著寫了一下發現實在很難講到讓人理解...不深入談又只有一句話【透過假設檢定的統計分析證明某變數是否會產生某影響】，又太膚淺，就暫且略過吧。

總之，數據分析方法百百種，沒有一定的套路。
就像是中式西式的師傅，各有所長，只要能烹飪出美味的料理，就是一位好師傅。

終於，我們把資料收集與處理過程，完整討論完了呢！

資料收集與處理過程 番外篇

鐵人賽進行完一半，
一如規劃的將文章收在(自認)蠻漂亮的段落。
算是把【資料收集與處理過程】這個階段給完整寫完。

明天開始下個階段，
但與其說下個階段，
也是承接在資料處理之後的內容，
還有哪些很重要的專有名詞還未登場？
大概就是講剩下的這群傢伙了。

之前一直以來的番外篇都太抱怨、太爭鬥、太黑暗，
今天來寫個比較單純歡樂陽光的番外好了，
來想想一些資料處理上開心的回憶。

嗯，我想不到。